Read the original article here.

---

Heap Spraying: A Forbidden Technique for Gaining Control

Welcome to the section on Heap Spraying in "The Forbidden Code." While standard programming courses focus on building secure applications, understanding the techniques used by attackers is crucial for truly mastering software and its vulnerabilities. Heap spraying is one such technique – not an exploit itself, but a powerful tool that makes exploiting certain vulnerabilities vastly more reliable. It's about manipulating memory layout to turn a fragile opportunity into a guaranteed path to code execution.

Understanding the Basics: Memory and Exploitation

Before diving into heap spraying, let's establish some foundational concepts.

Memory Heap: In programming, the heap is a region of memory used for dynamic memory allocation. This is where programs request chunks of memory of varying sizes during runtime (as opposed to the stack, which is used for local variables and function calls with a more structured, LIFO-like allocation). Allocations on the heap are managed by memory allocators and can happen in a less predictable order than stack allocations.

Exploit: A piece of software, data, or a sequence of commands that takes advantage of a bug or vulnerability in a system or application to cause unintended or unanticipated behavior. Often, this behavior is used to gain unauthorized access to data, execute arbitrary code, or disrupt service.

Arbitrary Code Execution (ACE): The ability of an attacker to run any command or code they choose on a target machine or process. This is typically the ultimate goal of exploiting many types of software vulnerabilities.

Exploits frequently target memory corruption vulnerabilities like buffer overflows, use-after-frees, or double-frees. These bugs allow an attacker to write data to unintended memory locations, sometimes overwriting critical data like pointers, function return addresses, or vtable pointers. If an attacker can overwrite a pointer used by the program to call a function, they can potentially redirect execution to code of their choosing – arbitrary code execution.

However, memory layouts can be notoriously unpredictable. The exact address of a specific variable, a freed object, or even a large allocated block can vary depending on factors like the operating system version, installed software, memory usage patterns, and even timing. This randomness makes reliable exploitation difficult. An attacker might need to guess the address of their malicious code or a useful gadget (small pieces of existing code) within the target process.

The Role of Heap Spraying

This is where heap spraying comes in. Heap spraying is a technique used within an exploit to increase the probability of successfully redirecting program execution to an attacker-controlled memory region.

Heap Spray: A technique used within exploits to place a large amount of attacker-controlled data (often containing shellcode or a NOP sled) at predictable locations within the process's memory heap. The goal is to make it highly likely that a corrupted pointer or address lookup will land within this sprayed region.

Think of it like this: If you need to hit a specific, tiny target from a distance but your aim is shaky, you can make the target much, much larger. Heap spraying makes a large area of memory the "target" for the vulnerability to hit.

The core idea is to force the target process to allocate many large blocks of memory on the heap and fill them with specific, attacker-chosen bytes. Because memory allocators often try to place consecutive large allocations sequentially, repeating this process multiple times creates a large, contiguous, or semi-contiguous region of memory filled with the same pattern. This region is then located at a relatively predictable base address across different runs of the program.

How It Works: Making the Heap Predictable

1. Massive Allocation: The attacker causes the target program to allocate a very large amount of memory on the heap. This is typically done by repeatedly requesting large memory blocks.
2. Filling the Blocks: Each allocated block is filled with a specific sequence of bytes chosen by the attacker. This sequence often contains:
   • A long string of "No Operation" (NOP) instructions, forming a "NOP sled."
   • The actual malicious code, known as "shellcode," placed at the end of the NOP sled or at strategic locations within the sprayed data.
   • Potentially, valid-looking data structures or pointers that the vulnerable code might expect.
3. Predictable Placement: Modern memory allocators, especially for large chunks, tend to place them in somewhat predictable locations or at least within a relatively confined address range. By allocating many large blocks, the attacker ensures that a significant portion of the heap space is occupied by their controlled data.

NOP Sled (or NOP Slide): A sequence of No Operation instructions (NOPs) in machine code. A NOP instruction does nothing but consume a clock cycle. A NOP sled is used in some exploits to increase the chances of successfully jumping to a target instruction (like shellcode). If an attacker can divert execution anywhere within the NOP sled, the processor will "slide" down the sled (executing NOPs) until it reaches the attacker's shellcode at the end.

A common byte pattern used in heap spraying is one that serves a dual purpose: it acts as a NOP instruction and can be interpreted as a valid memory address within the sprayed region itself. For example, on x86 architectures, the byte sequence 0x0c0c0c0c is sometimes used. 0x0c (decimal 12) can be interpreted as the INC ECX instruction. While not a true NOP, a sequence of INC ECX instructions often doesn't disrupt program flow significantly enough to cause a crash before hitting the intended payload, and 0x0c0c0c0c is also a potential memory address. If a corrupted pointer is read and its value is 0x0c0c0c0c, and the attacker has filled a large chunk of memory starting at 0x0c0c0c0c with their sprayed data (a NOP sled followed by shellcode), the program execution jumps into the NOP sled and slides into the shellcode.

Putting It Together: The Exploit Chain

A typical exploit using heap spraying involves these steps:

1. Heap Spray: The attacker runs code (often JavaScript, VBScript, or similar in a browser context) that performs the heap spray, filling a large, predictable area of the heap with their controlled data (NOP sled + shellcode).
2. Trigger Vulnerability: The attacker then triggers the specific vulnerability in the target application. This vulnerability must allow the attacker to somehow corrupt memory, typically by overwriting a pointer (like a function pointer, object pointer, or return address) with a value pointing into the sprayed heap area (e.g., 0x0c0c0c0c).
3. Redirect Execution: When the vulnerable code later uses the corrupted pointer, instead of jumping to its legitimate target, it jumps to the address specified by the attacker (which is within the sprayed region).
4. Execute Shellcode: Because the jump lands within the sprayed heap, execution begins at that point. If it lands in a NOP sled, it slides down into the shellcode. The shellcode then executes, allowing the attacker to perform their desired actions (e.g., download and run malware, steal data, take control of the system).

The reliability comes from the size of the sprayed region. Even if the vulnerability provides imprecise control over the overwritten pointer's value, as long as the target address falls somewhere within the vast sprayed area containing the NOP sled, the exploit is likely to succeed.

Historical Context and Prevalence

Heap spraying isn't a brand-new technique. It has been observed in exploits since at least 2001. However, its widespread adoption, particularly in web browser exploits, took off around 2005.

Web browsers became a prime target due to their complexity, large attack surface (processing various data formats, executing code like JavaScript), and the prevalence of memory corruption vulnerabilities in browser engines and plugins. JavaScript, being readily available and capable of allocating large strings, proved ideal for implementing heap sprays within a browser context.

The ease of implementing heap sprays using scripting languages meant that attackers could reuse the spraying code for various different vulnerabilities, making it simpler to develop reliable exploits. This significantly lowered the barrier to entry for creating effective web browser exploits, contributing to a surge in attacks targeting users simply browsing the web.

Implementation Techniques Across Environments

Heap spraying relies on the specific memory allocation mechanisms of the target environment. Here are some common ways it's implemented:

JavaScript (Web Browsers)

This is the most common method discussed historically.

// Example (Conceptual): JavaScript Heap Spray
var shellcode = unescape("%u9090%u9090..."); // Shellcode (unescaped to bytes)
var nops = unescape("%u0c0c%u0c0c...");   // NOP-like bytes (0x0c0c0c0c)
var spray_unit = nops.substring(0, 0x1000 - shellcode.length) + shellcode; // A large block ending in shellcode
var heap_blocks = new Array();
var spray_size = 0x400000; // Amount to spray (e.g., 4MB per block)

// Spray the heap
for (var i = 0; i < spray_size; i++) {
    heap_blocks[i] = spray_unit.substring(0, spray_unit.length); // Create and fill blocks
}

// Now, trigger the vulnerability... which aims for an address like 0x0c0c0c0c
// If successful, execution lands in one of the heap_blocks, slides down NOPs, hits shellcode

• Mechanism: JavaScript allows the creation and manipulation of large strings. Browsers often store these strings contiguously in memory. By creating extremely long strings filled with specific byte patterns (often represented using unescape or similar methods to insert arbitrary byte values) and then creating many copies of these large strings, attackers could force the browser's JavaScript engine to allocate vast amounts of heap space containing their malicious data. The strings are typically stored in an array to keep references to them, preventing garbage collection from freeing the memory prematurely.
• Byte Representation: JavaScript strings internally might use ASCII or Unicode. Attackers need to craft the byte sequence carefully to ensure it's interpreted correctly as machine code on the target architecture and operating system, regardless of the string encoding. The unescape function was historically useful because %uXXXX allowed inserting arbitrary 16-bit values, and %XX for 8-bit values, which could correspond to machine code bytes or NOPs.

VBScript (Internet Explorer)

Similar to JavaScript, VBScript in older Internet Explorer versions could be used to allocate large strings, serving the same purpose. The String function was a common tool for this.

ActionScript (Adobe Flash)

As vulnerabilities were found in browser plugins like Adobe Flash, heap spraying techniques adapted. ActionScript could be used to allocate large data structures or byte arrays within the Flash player's memory space, which resides within the browser process.

Images and Other Data Structures

While less common historically, the core principle applies: any mechanism that allows a program to allocate large, attacker-controlled data in memory can potentially be used for heap spraying. Loading large image files, for instance, requires memory allocation to store pixel data, and if the image format allows embedding arbitrary data or is malformed in a specific way, it could potentially be used for this purpose, although practical widespread use has been limited.

HTML5 Technologies (Canvas, Web Workers)

More modern techniques leveraging HTML5 demonstrate the technique's evolution.

• Canvas API: The <canvas> element provides a low-level interface for drawing graphics, often backed by pixel buffers (bitmaps) in memory. By creating large canvas elements and manipulating their pixel data programmatically, attackers can allocate and fill large, granular blocks of memory on the heap with attacker-controlled bytes.
• Web Workers: Web Workers allow running scripts in background threads. This can be used to parallelize the heap spraying process, allocating memory even faster and potentially occupying more of the heap space quickly.
• Granularity: Using techniques like Canvas allows for more fine-grained control over the size and content of the allocated blocks compared to simply creating large strings, potentially making the spray more effective against certain types of vulnerabilities or memory allocators.

Detection and Prevention

Heap spraying itself is difficult to prevent directly because it relies on legitimate mechanisms for memory allocation. However, countermeasures focus on making the exploit chain harder:

• Detection (e.g., Nozzle, BuBBle): These countermeasures monitor memory allocation patterns and content on the heap. They look for the characteristic signs of a heap spray: numerous large blocks allocated in quick succession, filled with repetitive or suspicious byte patterns (like long NOP sleds or sequences often associated with shellcode). If detected, the process can be terminated or flagged.
• Address Space Layout Randomization (ASLR): This is a fundamental defense technique that randomizes the base addresses of key memory regions (like the stack, heap, and libraries) upon program startup. While ASLR doesn't prevent heap spraying, it makes it harder for the attacker to know the exact address range where their sprayed heap will reside. However, heap spraying can sometimes mitigate the effects of ASLR by creating such a large target area that the random pointer is still likely to land within it. Or, attackers might use information leaks to defeat ASLR before attempting the heap spray.
• Data Execution Prevention (DEP) / W^X ("Write XOR Execute"): These security features mark memory pages as either writable OR executable, but not both simultaneously. Heap memory (where the spray occurs) is typically marked as writable but not executable. If DEP is enforced, the processor will prevent code from running directly from the heap. This forces attackers to use more complex techniques like Return-Oriented Programming (ROP) to bypass DEP, often requiring gadgets located in executable memory regions like libraries, rather than directly executing sprayed shellcode on the heap.
• Hardened Memory Allocators: Some memory allocators include features designed to disrupt heap spraying or make it less reliable, such as randomizing the placement of large allocations or filling unused portions of allocated blocks with non-executable data.
• Control Flow Integrity (CFI): CFI techniques aim to restrict the possible destinations of control flow transfers (like function calls, jumps, and returns) to valid targets. This would prevent a corrupted pointer from jumping into an arbitrary location like the middle of a sprayed heap block.

Related Techniques

Heap spraying is often used in conjunction with, or is related to, other memory manipulation techniques:

• NOP Sled: As discussed, a NOP sled is typically part of the sprayed data.
• Heap Feng Shui: A technique that aims to shape the heap layout before triggering a vulnerability. While heap spraying fills a large area somewhat predictably, heap feng shui involves carefully allocating and freeing blocks of specific sizes and patterns to position a target object or a freed chunk at a predictable location, often to make a use-after-free or double-free exploit more reliable. Heap spraying can be seen as a less precise, brute-force approach compared to the more delicate positioning of heap feng shui.
• JIT Spraying: A technique used to bypass DEP in environments that use Just-In-Time (JIT) compilation (like JavaScript engines). Instead of spraying raw shellcode onto the heap, the attacker crafts data that, when compiled by the JIT engine, becomes the shellcode or ROP payload in an executable memory region managed by the JIT compiler.

Conclusion

Heap spraying is a foundational technique in the attacker's toolkit for turning unreliable memory corruption vulnerabilities into reliable arbitrary code execution. By flooding the process heap with controlled data, often incorporating NOP sleds and shellcode, attackers create a large target area that increases the likelihood that a corrupted pointer will redirect execution to their malicious payload. While modern defenses like ASLR and DEP have made direct heap spraying of shellcode less straightforward, understanding this technique is essential for comprehending the history and evolution of software exploitation and the countermeasures developed to combat it. It highlights the critical relationship between memory management, program control flow, and the constant battle between attackers and defenders.